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REMARKS 

Claims 1-52 are all the claims presently pending in the application. 

It is noted that the claim amendments (if any) are made only for more particularly 
pointing out the invention, and not for distinguishing the invention over the prior art, 
narrowing the claims or for any statutory requirements of patentability. Further, Applicant 
Specifically states that no amendnient to any claim herein should be construed as a disclaimier 
of any interest in or right to an equivalent of any element or feature of the amended olaizru 

Claims 5-13 and 3 1 -39 are allowed . Applicant gratefully acknowledges that claims 
15, 26, 41, and 52 would be allowable if rewritten in independent form. However, Applicant 
respectfully submits that all of the claims are allowable, when properly interpreted consistent 
with the plain meaning of the claim language in the independent claimS) as clarified in the 
discussion below. 

Claims 1-4, 14, 16-25, 27-30, 40, and 42-51 stand rejected under 35 U.S,C, § 103(a) 
as unpatentable over U.S. Patent No. 6,134,245 to Scarmalis, further in view of "Generic 
Framing Procedure (GFP) Specificatiorf\ October 9-13, 2000, by Hernandez-Valencia (Ed.). 

This rejection is respectfully traversed in the following discussion. 

1. THE CLAIMED INVENTION 

The clidmed invention is directed to a GFP frame transfer apparatus for transferring a 
GFP (Generic Frame Procedure) fiame over a GFP network. An FCS generation section 
generates, when the GFP frame is generated and sent by the GFP frame transfer apparatus, an 
FCS (Frame Check Sequence) using the pavload field of the GFP frame as the generation 
target area a nd adds this FCS to the FCS field of the GFP frame. 

As explained beginning at line 13 on page 6, conventional methods update the 
pavload header and recalculate the FCS. Although it is possible to perform monitoring in 
ring units using the FCS field, it is not possible to perfoma monitoring of the end-to-end path 
from the SONET node of Ingress to the SONET node of Egress. 

The claimed invention, on the other hand, provides a method for performance 
monitoring of an end-to-end path using the FCS field of a GFP frame. It achieves this 
capability by generating an FCS using the pavload of the GFP frame as the generation target 
area and adding this to the FCS field of the GFP frame. 
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n. THE PRIOR ART REJECTION 

The Examiner alleges that ScarmaliSs further in view of Hernandez-Valencia, renders 
obvious the claimed invention as defined by claims 1-4, 14, 16-25> 27-30, 40, and 42-51. 
Applicant submits, however^ that there are elements of the claimed invention which are 
neither taught nor s\iggested by Scaimalis, even if modified by Hemandez- Valencia. 

The Examiner seems to maintain the rejection by considering that adding new PCS to 
the PCS field of the GFP frame is obvious to the person having ordinary skill in the art. 
However, Applicants submit that this is not an aspect of the present invention chat is 
particularly significant compared to the conventional method. 

That is, more significant is that the target area for a conventional FCS calculation 
corresponds to the entire navload area of the GFP frame, while the target area of the present 
invention corresponds to the pavload (field) part without the payload header (p.25, line 27, to 
26, line 3, in the specification of the present application). 

ThuSj in Enrique Hemandex- Valencia, the area corresponds to the entire payload area . 
Also, in Scamalis, the area corresponds to the entire area of the HDLS packet excluding a 
begin flag and an end fiag (coL 6S, line 5 1 — coL7, line 8 in Scamalis). Both of these 
references are difierent from the present invention in the target area for FCS calculation. 

In the cited references, the fields in the pavload header of the GFP fi^ame (or HDLC 
packet) is rewritten at each node that terminates the GFP fi-ame (or HDLC packet), so that 
FCS is recalculated and rewritten at the node (p.6, lines 6-13 in the specification). On the 
other hand, the present invention does not need both recalculating and rewriting at the node . 
since the target area for calculating FCS does not have the pavload header (p.25, line 27 to 
p.26, line 6 in the specification). 

The tstxget area for a FCS calculation of the present invention corresponds to the 
pavload files without pavload header . The target area for a conventional FCS calculation 
corresponds to entire area of the pavload area (including payload header) . 

The Examiner's continued rejection suggests a failure to recognize this sigxxificant 
difference of the respective tai*get areas. 

TI^ reference US 6,134,245 (Scarmalis) does not include the above subject matter of 
ttie present invention. Applicants explain the frame format and the target area for FCS 
calculation of Scarmalis in the following discussion. 

The fi:3me format shown in Fig.5 in Scarmalis is the Frame Relay format, which is 
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spedlSed in ITU-T Recommendation Q.921 and Q.922. For the information of the Examiner, 
the front cover page of each of these two ITU publications is attached to this paper, along 
with a copy of selected pages mentioned below. It is noted that, because these documents are 
publicly available and quite lengthy (e.g., 269 p^es and 112 pages, respectively), Applicants 
have not submitted a complete copy but can do so if the Examiner considers such complele 
documents should be added to the file and contacts Applicants' representative at the contact 
infonnation at the end of this paper. 

The specification of the frame format is described in *'Figurel/Q.921 - Frame 
formats" of ITU-T Q.921 and the specification of Frame Relay is described in Annex A of 
ITU-T Q,922. The format corresponds to Format B in "Figure l/Q-921 - Frame formats" of 
mi-T Q.921, which is copied below as an imported figure. 
Q,921. 
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Figure 1/QJ>21 - Frame formats 



The target area for FCS calcxilation in Frame Relay (which is Scarmalis's target area) 
is described in Section 2.7 "Frame Check Sequence (FCS) field" of ITU-T Q.921. That is, 
the target area for FCS calculation is from the next bit of the last bit of the start Flag (that is, 
first bit of the Address field) to the previous bit of FCS. Hence, the target area for FCS 
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calculation in Frame Relay includes the Address field. 

The specification of Address field in Frame Relay is described in Section 3 "Elements 
of procedures and formats of fields for data link layer peer-to-peer communication" and 
ANNEX-A "Core aspects of Q.922 for use with fi-ame relaying bearer service" of ITU-T 
Q.922, The format in Frame Relay is described in p.31 FIGURE A-i7q922 Frame relay 
frame format with two octet address of ITU-T Q.922, copied below as an imported figure. 
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The specification of the Address filed format is described in FIGURE A-2/Q.922 
Address field formats of ITU-T Q.922, copied below as an imported figure. 





8 7 6 


S 


4 


3 


2 


1 








* 


EA 
9 




LomrDLCI 


FBCN 


BECK 




EA 

1 






OK 












8 7 6 


5 


4 


3 




1 


J DctetaddreM 


UiipvDLCX 


« 


EA 
0 




DLCI 




9ECW 




£A 
0 




DL-CO!R£ eonnol 




£A 
1 



8 7 » S 4 3 2 1 



UppiirDLCI 




£A 






0 




FECK 


BECN 




£A 










0 


DLCI 




EX 






0 


Lows DLCr oar 




EA 


OL-CORE coeaol 




1 



D/C DLClarDl^CC^Ecutttel uidieAter (m* $ A3.i.7> 

DE Discard «lif ibilitjr mdie^lor Cm $ 

EA Address £cld aOleasam bil (9M j A J3rl) 

* Bit m^Bwifii to wrpatt a cjomaaaifzmjpaaam iadtcieoo. TtM oedav la aRpiieauoB a^tdfie (act 5 

FBCN Fonvaid ercplicst cose«:rtiosL nonfzcjitioa (l^M § A,3. X 3) 

B£CN Badnffixd txpNcit congiestian witifffatioa (see 9 A^.3.4> 

DLd D«ta&ik€Oa»lt«i«>i&alificr<3c*5A.3.3.6} 



FIGURE AfZO}^ 



22 

PAGE24ffi0'RCVDAT4/12f20083:31:54PM{EastemDayflght^^^ 



04/12/2006 14:36 FAX 7037612375 



MCGINN IP LAV 



PTO 



g|025/060 



, Serial No. 10/022,594 
Docket No. 396290/00 

The bit of FECN, BECN and DE may be changed by the network-equipment in a 
route, as shown in Sections A.3.33, and (page 32-34) of ITU-T Q.922. 

Hence, in Frame Relay, the bit in the tax:get area for PCS calculation may be changed in a 
network equipment in a route. 

Applicants believe that the subject matter of the present invention is not disclosed in 
any reference and is not obvious from any reference currently of record. 

Hence, turning to the clear language of the claimed invention, in neither Scaimalis nor 
Hernandez- Valencia is there a teaching or suggestion of: "►..when said OFP frame is 
generated and sent by said GPP frame transfer apparatus, an FCS (Frame Check Sequence) 
using a pavload field of said GFP frame as a generation target area and adds this FCS to the 
PCS field of said GFP &dme"» as required by independent claim 1. The remaining rejected 
independent claims have similar language. 

Therefore, Applicants submit that there are elements of the claimed invention that are 
not taught or suggest by Scarmalis, even if modified by Hemaivlez-Vaiencia. Therefore, the 
Examiner is respectfiilly requested to reconsider and withdraw this rejection. 

A^licants again respectfully submit that die rejection currently of record fails to 
provide a reasonable motivation to modify the primary reference. Moreover* even if the 
primary reference were to be modified, the basic deficiency identified above for the primary 
reference would still not be overcome. 

m. FORMAL MATTERS AND CONCLUSION 

In view of the foregoing, Applicant submits that claims 1 -52, all the claims presently 
pending in the application, axe patentably distinct over the prior art of record and are in 
condition for allowance. The Examiner is respectfiilly requested to pass the above 
application to issue at the earliest possible time. 

Should the Examiner find the application to be other than in condition for allowance, 
the Examiner is requested to contact the undersigned at the local telephone number listed 
below to discuss any other changes deemed necessary in a telephonic or personal interview. 
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The Commissioner is hereby authorized to charge any deficiency in fees or to credit 
any oveipayment in fees to Attorney's Deposit Account No. 50-0481. 



Respectfully Submitted, 



Date: 




Frederick E. Cooperrider 
Registration No. 36,769 



McGinn Intellectual Property Law Group, PLLC 
8321 Old Courthouse Road, Suite 200 
Vienna, VA 22182-3817 
(703) 761-4100 
Customer No. 21254 



CERTmCATIQN OF TRANSMISSION 

I certify that I transmitted via facsimile to (571) 273-8300 this Amendment under 37 
CFR §1.116 to Examiner S.C. Horn on April 12, 2006. 




Frederick E. Cooperrider 
Reg. No. 36,769 
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( 



abort sequence is not simulated within the frame. A receiving data link layer entity shall examine tht- 
frame contents between the opening and closing flag sequences and shall discard any 0 bit whicl 
directly follows five contiguous 1 bits, 

Frame Check Sequence (FCS) field 
The FCS field shall be a 16-bit sequence. It shall be the ones complement of the sum (modulo 2) of: 

a) theremainderofx*(x»5+x^^ + ;c*34.x'2^;c'*+x^^ + r^H-;c«+;c^+;t'^ 
1) divided (modulo 2) by the generator polynomial jc** + jc'^ +;c^ + 1, where k is the nurabei 
of bits in the frame existing between, but not including, the final bit of the opening flag and 
the first bit of the FCS, excluding bits inserted for transparency; and 

b) the remainder of the division (modulo 2) by the generator polynomial + x*^ + + l, oJ* 
the product of*»« by the content of the frame existing between, but not including, the final 
bit of the opening flag and the first bit of the FCS, exchiding bits inserted for transparency. 

As a typical implementation at the transmitter, the initial content of the register of the device 
computing the remainder of the division is preset to all Is and is then modified by division by the 
generator polynomial (as described above) on the address, control and information fields] tfie ones 
complement of the resulting remainder is transmitted as the 1 6-bit FCS. 

As a typical implementation at the receiver, the initial content of the register of the device computing 
the remainder is preset to all Is. The final remainder, after multiplication by then division 

(modulo 2) by the generator polynomial x»e + + jc^ + l of the serial incoming protected bits and 
the FCS, will be OOOlllOlOOOOllU (x** through acO, respectively) in the absence of transmission 

errors^ ^^^ _ 

^ 2.8 Format convention 
2.8.1 Numbering convention 

The basic convention used in this Recommendation is illustrated in Figure 2. The bits are grouped 
into octets. The bits of an octet are shown horizontally and are numbered from I to 8. Multiple octets 
are shown vertically and are numbered from 1 to a. 

2.8^ Order of bit transmission 

The octets are transmitted in ascending numerical order; inside an octet bit 1 is tiie first bit to be 

transmitted. 

2.8.3 Field mapping convention 

When a field is contained within a single octet, the lowest bit number of the field represents the 
lowest order value. 

When a field spans more than one octet, the order of bit values within each octet progressively 
decreases as the octet number increases. The lowest bit number associated with the field represents 
the lowest order vahie. 

For example, a bit number can be identified as a couple (o, V) where o is the octet nxunber and h is 
the relative bit number within the octet. Figure 3 illustrates a field that spans fit)m bit (1, 3) to bit 
(2» 7). The high order bit of the field is mi^ped on bit (1, 3) and the low order bit is mapped on bit 
(2,7). 

An exception to the preceding field mapping convention is the data link layer FCS field, which spans 
two octets. In this case, bit 1 of the first octet is the high order bit and bit 8 of the second octet is the 
low order bit (see Figure 4). 
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d) contains a frame check sequence error, 

e) contains a single octet address field; or 

f) contains a DLGI which is not supported by the receiver. 
Invalid frames shall be discarded widiout notification to the sender. No action i$ taken as the result of invalid 

frames. 

2.10 Frame aborts 

The definition of and the reaction to fiame aborts is as iix Recommendation Q.921 [2]. 




3 Elements of procedures and formats of fields for data link layer peer-tc^peer communication 



3.1 General 

The elements of procedures define [he commands and respomea thAt are used for peer-^to-peer communication 
usiog the data link layer connections. 

Procedures are derived fiom these elements of procedures and are described in § 5. 



3.2 Address field format 

The address field format shown in Figure 1/Q.922 contains the address field extension bits, a 
command/response indication, 3 bits reserved for forward and baclcward explicit congestion notification and discard 
eligibility (used with fiame relaying services per Annex A), a data link connection idratifier (DLCl) field and a bit Co 
indicate whether the final octet of a 3 or 4 octet "address field" is lower DLCI or Dl^CORE control (see § 3.3.7) 
information. The minimum and default length of the addr^s field is 2 octets and it may be extended to 3 or 4 octets to 
support a larger DLCI address x^nge or to support optional DL-CORE control f\mctioas. The 3-octet and 4-octet address 
field fonmats may be supported at the user^network interface or at the network-network interface based on negotiation or 
bilatexd agreement 



The support of address fields longer than two octets is an option chosen by bilateral agreement. This option 
includes distinctiona ibr supporting the address field length varying on an interface basis or on a per channel basis. 

3.3 Address field variables 

3 .3. 1 Address field extension bit (EA) 

The address field range is extended by reserving the first transmitted bit of the address field octets to indica[e 
the final octet of the address field. The presence, of a 0 in the first bit of an address field octet signals that another octet 
of the address field follows this one. The presence of a 1 in the firsi bit of en address field octet signals chat it is the final 
octet of the address field For exan^le* the two octet address field has bit one of the first octet set to ''O" and bit one of 
the second octet set to T\ 

3-3.2 CcmmamVresponse field bit (OJ^ 

The C/R bit identifies a frame as either a command or a response. When the frame to be sent is a command 
fr«ne, the C/R bit shall be set to 0. Whon the fiame to be $cnt is a response frame, the C/R bit shall be set to 1 . 

33 J Forward explicit congestion notSfteattan bit (FECN) 

This bit is reserved for use wifii firame relayiog sovice, as described in Aimex A and Appendbc I. 



P«E29in'IO)AT«l2l2IH3:]1j(n|NltmDi||lgMnae|'S1IM^ , y' ^ 



04/12/2006 14:37 FAX 7037612375 



De&ult address 
field foncat 
(2 octets) 



3 octets ftddrtss 
field format 



NC6INN IP LAW 



-» PTO 



or 



@1 030/060 



8 7 6 5 


4 


3 


2 


1 


Upper DLCI 


C/R 


EA 
0 


Lower DLCI 


FECN 
(Note) 


BECK 
(Note) 


DE 
(Note) 


EA 
I 



Upper DLCI 


C/R 


EA 
0 


DLa 


FECN 
(Note) 


BECN 
(Note) 


DE 
(Note) 


EA 
0 


Lower DLCI or 
DL-CORE control 


D/C 


EA 
1 



or 



4 octets address 
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EA Address field extension bit 

C/R Command response bit 

FECN Fonvfird eKplicit congestion notification 

BECN Backward explicit congestion notification 

DLCI Data link eonneccioii identifier 

DE IMscard eligibiUty indicator 

D/C DLCI or DL-CX)RE oontiol indicator 

iVore — See Annex A and Appendix I for the use of tliese 3 bits wbictie are reserved for congestion notificatiDn signalling with frarnc 
relaying. 



nGURE 1/Q.922 
Address field formats 
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3.3.4 Backward explicit eongG:stiQn notification bit (BECN) ' 
This bit is reserved for use witii frame relaying service, as described in Aimex A and Appendix I. 

3 J.5 Discard eligibility indicator (DE) 

This bit is reserved for use with frame relaying service, as described in Annej^ A and Appepndix L 

3.3.6 Data link connection identifier (DLCO 

The DLCI identifies a virtual connection cm a bearer channel (i.e. D, B or H) at a user to network or netivork to 
network interfece. Consequently^ a DLCI specifies a data link layer entity to/fipom which information is 
delivered/received and which is to be carried in frames by data link layer entities. The DLCI field may be either 
unstmctured or structured. In die former case, the least significant bit is determined as follows: 



Address field D/C » 0 D/C = 1 

si^e 

2 octets (Note) (Note) 

3 octets bit 3 of octet 3 bit 5 of octet 2 

4 octets bit 3 of octet 4 bit 2 of octet 3 

Note - Not applicable; least significant DLCI bit is bit 5 of octet 2. 

A structure to the DLCI field may be established by the network at the user to network inter&ce or ax a 
network to network inter&ce subject to negotiation or bilateral agreement. 

For notation purposes, die 6 most significant bits (bits 8 to 3) in the first octet of the addr^s field (which 
correspond to the SAFI field in Recommendation Q.92 1 [2]) are referred to as the upper DLCI. 

Table 1/Q.922 shows the ranges of DLCI values which apply for specific functions to ensure conq)atibiIity 
with operation on a D-channel, which also may use the Q.921 (2] protocol. A two octet address field format for this 
Recommendation is assumed when used on a D'<J3annel. For further study is whether 3 or 4 octet address field formats 
may be used on a D-channel. 

3 J.7 DLCI/DL-CORE control indicator (D/C) 

The D/C indicates whether the remaining sfat usable bits of that octet are to be interpreted as the lower DLQ 
bits ot as DL-CORE control bits. The bit is set to 0 to indicate that the octet contains DLCI information. This bit is set to 
1 to indicate that the octet contains DL-CORE control ixifomiation. This indicator is limited to use in the last octet of the 
three or four octet type ''address field". The use of this indication fbr DL-CORE control is reserved as there have not 
been any additional control fiinctions defined which need to be carried in the "address field"; this indicator has been 
added to provide for possible future expansion of the protocol 

Note - The optional DL-CORE control field is part of the address field and therefore must not be confused 
with the control field of an HDLC firame as defined in Figure 1/Q.92I. 



3.4 Control field formats 

The control field identifies the type of frame, which will be either a command or response. The control will 
contain sequence numbers where applicable. 

Three types of control field fonmts are specified: numbered information transfer (I format), supervisory 
fractions (S format), and unnumbered infbrniation ccansfbrs and control functions (U fbmat). The controi field formats 
att shown in Table 2/0.922. 
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TABLE I/Q.922 
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10 bits DLGIs (Note 1) 


DLCI range 


Function 


0 (Note 2) 


In channel sijwallmR, if requiicd 




Reserved 


16-511 


Network option: on non-D-channels, available for suDDOrt of user information 
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LoRical link identiflcation for support of user information Q4oib 6) 


992-1007 


Layer 2 manaKement of frame mode bearer sorvica 


1008-1022 


Reserved 


1023 (Note 2) 


In channel layer 2 management, if required 


lebitsDLas (Note 3) 
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Function 


0 (Note 2) 


In channel siiniaflins, if leauircd 


1-1023 


Reserved 


1024-32767 


Network option: on non-l>'ehtinnel8, available for suppon of user infonnadon 


32768-63487 


Logical link identification for support of user information (Note 6) 


63486^511 


Layer 2 mBnaaemoni of frame mode bearer service 


64512-65534 


Reserved 


6SS3S(Not6 2} 


In channel layer 2 managemsnt, if required 


17bitaDLCIft(No»4) 


DLCI range 


FUnetion 


0CNotc2) 


In channel sienalHnB, if required 


1-2047 


Reserved 


2D4B-65 535 


Network oprion: on non-D-channels, available for support of user information 


65536-126975 


Logical link identification for support of user information (Note 6) 


126976-129023 


Layer 2 management of frame mode bearer service 


129024-131 070 


ResBTVcd 


13107] (Note 2) 


In channel layer 2 management, if required 


23 bits DLCIs (Note 5) 


DLCI range 


Function 


0 CNotc 2) 


In channel signalling, if required 


1-131 071 


Reserved 


131072^ 194303 


Nccworic option: on non^D-channels, available for suppon of user infomiadon 



Note J — These DLCIs apply when a 2 octet address field is u sed or when a 3 oeret address field is used with D/C = I . 
Note 2 — Only available within non-D-channel. 

Note 3 — These DLCIs apply for non-D-channels when a 3 octet address field is used with D/C 0. 
Note 4 — These DLCIs apply for non-D-channels when a 4 octet address field is used with D/C - 1 . 
Noi£ 5 — Those DLCIs apply for non-D»channels when a 4 octet address field is used with D/C » 0. 
Note 6 ~ The use of senri-pernument {rame mode connections may reduce tiie number of DLCIs svBilablo from this range. 
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TABLE 2/Q.922 
Cootrol field rorman 



Control field bits 
(raodulo 128) 


8 


7 


6 


5 


4 


3 


2 


I 




I (bnnat 


N(S) 


D 


Octet 4 (Nate) 




NCR) 


P/F 


Octet 5 


SfORnat 


X 


X 


X 


X 


Su 


Su 


0 


I 


Octet 4 




N(R) 


P/F 


Octets 


Ufonnat 


M 


M 


M 


P/F 


M 


M 


1 


! 


Octet 4 



N(S) lYansmitcer send sequence number 

NCR) TIransiinltter receive sequonee mimbor 

P/F Poll bit when used as a command, 
final bit when used as a response 

X Reserved and sec u> 0 

Su Supervifloiy function bit 

M Modite fbnation bit 

Note — The identifioation of diese octets is consistent whith a 2 octet address field. 

Ihe vahies will be increased by 1 for a 3 octet address field and Vy 2 for a 4 octet address field. 



3 .4. 1 Information transfer (I) format 

The I fonnat shall be ttsed to perform an mfbrmation transfer between layer 3 entities. The functioofi of N(S), 
N(R) and F/P (deSnod in § 3.S of ftecommoAdation Q.921 [2]) are independent; that is, each I frame has a N(S) 
sequence number^ and a N(R) sequence number which may or may not acknowledge additional I fiBmes received by die 
data link layer entity, and a P/F bit that may be set to 0 or 1. 

The use of N(S), N(R) and P/F is defined in § 5 of Rccotxjtnendation Q.921 (2]. 
Note - This I fonnat diffeis from diat of LAPD because LAPP allows the use of the F-bit 
3.4^ Supervisory (S) format 

Ihe use of ttie S fonnat is the same as that specified in Recommendation Q.921 [2]. 

3.4.3 Unnumbered (U) format 

The use of the U fonnat is the same as that specified in Recommendation Q.921 [2]. 

3.5 Control field parom^t^rs and associated ^tate variables 

The various parameters associated widi the control field formats art described in Recommendadon Q.^I [2]. 
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3.6 Frame types ' 

3.6.1 Commands and responses 

The following commands and responses are used by either the user or the network data link layer entities and 
are represented in Table 3/Q.922. Each data Hnk connection shall support the full set of commands and responses for 
each a^Ucation implem^ted. The firame types associated with each of the two applications are identified in 
Table 3/Q.922. 

Frame types associated with aix application not implemented shall be discarded and no action shall be taken a? 
a result of that ftame. 

For purposes of the LAPP procedures in each application, those encodings not identified in Table 3/Q.922 are 
identiiied as undefined command and response fields. The actions to be taken ere specified in § 5.8.5. 

The commandfl and responses in Table 3/Q.922 are defined in §§ 3.6.2 to 3.6.12. 



TABLE 3/Q.922 
Commands and responses — modulo 128 



Application 


Format 


Commands 


Responses 


Encoding 

8 7 6 5 4 3 2 1 


XJiiaGkn0wle4fi6d 
and muldple frame 
acknowledged 
inftmtationtrazisfflr 


I 


I 


I 


N(S) 


0 


N<R) 


P/F 


S 


RR 


RR 


0 0 0 0 0 0 0 1 


N(R) 


P/F 


RNR. 


RNR 


0 0 0.0 0 1 0 1 


N(R) 


P/F 


RET 


REJ 


0 0 0 0 t 0 0 


1 


N(R) 


P/F 


U 


SABME 




0 1 1 


p 


1 1 I I 




DM 


0 0 0 


F 


1111 


UI 




0 0 0 


P 


0 0 1 ) 


DISC 




0 ] 0 


P 


0 0 1 1 




UA 


0 1 1 


F 


0 0 1 \ 


FRMR 


1 0 0 


F 


oil 1 


Conaaedon maaagement (Note 
0 


u 


XID 


XTD 


1 0 1 


P/P 


III 1 



ATo/e I — Consiestion nmnsgcmont is included in this row of die table. 
M»/tf 2— Use of (he SRBJ framo is for fixrther study. 
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3,$^ If^QrmQtiQn command/response 

Tlie function of the mfonnsitioD (I) frame is to transfer^ across a data link connection, sequendally nxnnbered 
frames coxxtainit^ informadon fields provided by layer 3. Iht I comxnand is used in the multiple frame operation on a 
point-to-point data link. The I response may be received by the data link layer entity in the multiple frame operation on a 
point-to-point data hnk. 

Note - This differs from LAJPD by adding information response frames. 

3.6.3 Sei asynchronous balanced mode extended (SABME) command 

The SABME tmnumbered command is defined in Recommendation Q.921 [2]. 

3.6.4 Disconnection (DISC) command 

The DISC unnumbered command is defined in Recommendation Q.921 [2]. 
3.6.3 Unnumbered iTffbrmation (UI) command 

The UI tmumbetod command is defined in Recommendation Q.921 [2]. 

3.6.6 Receive ready (RR) command/response 

The RK supervisory frame is defined in Recommendation Q.921 [2]. 

3.6.7 Ri^ect (REJ) command/response 

The REJ 5i9)ervi50iy frame is defined in Recommendation Q.921 [2]. 

3.6.8 Receive not rea^ (RNR) command/response 

The RNR supervisory frame is defined in Recommeodatioa Q.921 [2]. 

3 .6.9 XJnnimbered acknowledgement (UA) response 

The UA unnumbered response is defined in Recommendation Q.921 [2]. 

3.6.10 Disconnected mode (DM) response 

The DM unnumbered response Is defined in Recommendation Q.921 [2]. 

3.6. 1 1 Freme reject (FRMR) response 

The FKMR unnumbered response may be sent or received by a data link layer entity as a report of an error 
condition not recoverable by retransmission of the identical firame, i.e., at least one of the following error conditions 
resulting from the receipt of a valid frame: 

a) the receipt of a command or response control field tbat is undefined or not implemented; 

b) the receipt of a supervisory frame Or unmimbered frame with incorrect length; 

c) the receipt of an invalid N(R); or 

d) the receipt of a frame wi& an I field that exceeds the maximum established length. 

An undefined control field is any of the control field encodings that are not identified in Table 3/Q.922. 

A valid N(R) field is one diat is in the range V(A) £ N(R) £ V(S), where V(A} is the acknowledge state 
variable and V(S) is Ae send state variable (see §§ 3.5^2 and 3.5.2.3 of Recommendation Q.921 [2]). 

The FRMR re^nse frame infbnnation field is defined m Recommendation Q.921 [2]. 
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3.6. 1 2 Exchange identification (XJD) command/response 

The XID frame is defined in Recommendation Q.921 [2] for the connection management application. For the 
congestion management application, che XID frame is defined in Annex A. 



4 Elements for layer-to-layer communication 



4,1 General 

ConuDunicatians between layeis and, for this Recoounendation, between flie data link layer and the layer 
nsanagement are accomplished by means of primitives. 

Prinutives represent, in an abstract way, the logical exchange of information and control between the data link 
and acyacent layers. They do not specify or constrain implementations. 

An architectuial model showing the relationships among the layers and sublayers of both the C-plai:ie and the 
U-plane, together with their layer management entities and system jmnegement, is given in Figure 2/Q.922, In this 
model, a key conqwnent is tiie synchronization and convergence Auction (SCF) within the networic layers of both the C- 
plane and the U-plane. This SCF coordinates connection establishment and release between the C-plane and the U-plane. 
The SCF and the U-plane layer 3 fimctiotis ate outside the scope of this Recommendation. 

An overview models illustratiag the flow of messages and service primitives, is provided in Figures 3/Q.922 
tfirough 6/Q.922. These figures provide more detailed flow infonnation for the model illu^traied in Figure 2/Q.922. For 
simplification of representation, the C-plane layer 3 fUnctioiial block has been merged with die U-plane layer 3 
functional block and with the SCF. Only the DL-SAP m the U-plane is shown; the DL-SAP in the C-plane in support of 
signalling is not ilhistiated. 

Primitives consist of commands and their respective responses associated with the services requested of a 
lower or an upper layer. The general syntax of a primitive is: 

XX - Generic name - Type: Parameteis 

where XX designates the inter&ce across which t he primitive flows. For this Recommendation, XX is: 

- DL*COR£ for conomunications between the DL-CORE user and the DL-CORE (discribed in § A.4); 

- DL for communications between layer 3 and the data link layei^ 

- FH for communications between the data link layer and the physical layei^ 

- MC for communication between the DL-CORE and layer 2 management (described in § A.4); 

- MDL for conununjcations between die layer 2 management and the data link layer; or 

- M2N for communicadons between Oie layer 3 and layer 2 management entides. 

A general representation of primitive interactions with frame types within the U-plane and 1^^ 3 messages 
within the C-plane is described in Figures 3/Q.922 througji 6/Q.922. 

Ibe U-plane layer 2 fuxxctioxial block sv^rts the h^rer 2 protocol procedures in accordance with this 
Reconnnendadon. Layer 2 U-*plane sendees are provided at DL^SAP and may be invoked by the service user by means 
ofDLrprimitives. 

The layer 3 fbnctiona] block includes die fbncdonality fbr call control within the C-plwie (Q.933 [3] call 
control procedures), the layer 3 U-pIane functionality and the functions to perform coordination between C- and U-plane 
layer 3 endtlK. 
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ANNEXA 



(to RdCOrotnendatioQ Q.922) 



Core aspects of Q.922 for use with frame relaying bearer service 



A-1 General 

This annex describes Oie core aspects of Q.922 for use with the fiaxne relaying bearer service by identifying 
the dififeraices between Ae main text of this Reconnnendation and the structure necessaiy to support a frame relaying 
pTDtocoL 

This annex contains the flrame structure, elements of procedure, format the fields and procedures for the proper 
operation of the fiame relaying FMBS layer 2 protocol as described in Recommendation L122 [11] and service 
description Reoommendatioo L233 [1]. The core ai^ects of Q.922 provide for transparent transfer of DI^CORE service 



Note - The core aspects of Q.922 as defined in this amiex may be used with or without the elenoeats of 
procedures of LAPP. 

This protocol is a subset of LAPP. It is intended to: 

- share the core fimctions of LAPP as defined iu Recommendation 1.233 [1]; 
be used on any ISDN channei; axxd 

- operate on the D-channel concurrently with the LAPD protocol as defined in Recommendatioa Q.921 [2]. 

It assumes that data link identification is determined via group signalling or by prior agreement Group 
signalling is defined In Appendix U. 

The core fbncdons of LAPP used to support the frame relaying bearer service are considered to be: 

- frame delimiting, alignment and transparency* 

- frame multrplexing/demultiplexiog using the address field; 

- inspection of the fi^ame to ensure that it consists of an integral number of octets prior to zero bit insertion 

of following zero bit extraction; 

«- inspection of the frame to ensure that it is neither too long nor too short; 

- detection of (but not recovery from) transmission eirors; and 

- congestion control functions. 

A.2 Frame structure for peer-io-peer communicaiion 
A2A General 

All data link layer peer-to-peer exchanges are in frames conforming to the format shown in Figure A-1/Q.922. 
A.2.2 Flag sequence 

See § 2.2. 
A.2.3 Address field 

The address field shall eonsist of at least two octets, as illustrated in Figure A-1/Q.922 but may optionally be 
extended up to 4 octets. The format of the address field is defined in § A.3^. 



PJUX37l60'RCVDAT«12l20063:31:S4PM[EasteniDayipM]'SVK^ ), 



user data. 




04/12/2006 14:38 FAX 7037612375 



MCGINN IP LAV 



^ PTO 



@j038/060 



% 


7 6 5 4 


3 


2 


1 






Flag 










0 


1111 


I 


1 


0 


Oetetl 




High order octet of address Held 




(Note) 




2 




Low oidar octet of address Held 








3 












4 




Frame relay infbnnatioii field 




















N.3 




Fisme check sequence (FCS) 1st octet 








N.2 




Frame check sequence (FCS) 2nd octec 








N-1 




Flag 










0 


1111 


1 


1 


0 


N 



Note. - The de&iilt address field length is 2 octets. It may be extended to either 
3 or 4 ocoets bilateral agreement 



nGURBA-l/Q922 
FraiiM relay frame fbrmel with two octet address 



KXA Control field 

A control fields as seen by the DL-CORE Subkyer^ does not exlai in a frame relay fiame stnietiire. 
A-2.5 Frame relaying information field 

The frame relaying informatiott field of a &aine» when present, follows the address field (see § A.3.2) and 
precedes the frame check sequence field (see § A.2.7). The contents of the frame relaying information field shall consist 
of an integraJ number of octets. 

The minfimiim number of octets in the &ame relaying information field is defined in § 
A.2.6 Transparency 

A transmitting data link layer entity shall examine the frame content between the opening and closing flag 
sequences, (address, infoimatioD and FCS fields) end shall insert a **0" bit after all sequences of five contiguous "1" bits 
(including the last five bits of the FCS) to ensitre that a flag or an abort sequence i$ not simulated within the jSrame. A 
receiving data link layer entity shall mamm the frame contents between the opening and closing flag sequences and 
shall discard any ^'0** bit which directly fbllows five contiguous "1** bhs. 

A^.7 FramB cheeking sequence (FC^ field 



The definition and use of the FCS is as described in § 2.7. 
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A.2.8 Format convention 




The deflnitioiis of foimats and nxmibering conventions are as describe in § 2.8. 
A.2.9 btvedldfram^ 

The definition of invalid frames is as described in § 2.9. 

If a frame which is too lotSig is received by the netwoik, Oie netwoik may: 

- discard llie frame (see Note); 

- send part of the frame toward the destination user, then aboit the frame; or 

- send the complete frame toward tbe destination user with a valid PCS. 

Note - This approach implies that the implementation of the Q.922 protocol can not exploit the capabilities to 
discriminate among comipted ot too long frames. 

Selection of one or more of chese behaviors is an option for designers of frame relay network equipment and is 
not subject to ftutfaer standardization. Users shall not make any assumption as to which of these actions the network will 
take. In addition, the network may optionally clear tiie frame relay call if the number or frequency of too-long frames 
exceeds a network specified threshold. 

A.2.10 Frame abort 

Hie definition of and reaction to a frame abort is discussed in § 2.10. 



A.3 Elements of procedures and formats of fields for the DL^ORE service sublayer 
A.3.1 Generttl 

The elements of procedures contained in this armex are used by the DL-CORE service sublayer to itoplement 
optional procedures for congestion management which are found in § A.6. 

A.3.2 Address field format 

The format of &e address field is shown in Figure A-2/Q.922. This field includes the address field extension 
bits, a bit reserved for ^ by end user equipment intended to $upport a comztiand/response indicationi forward and 
backward congestion notification bits, discard eligibility indication, an indicator for DLCI or DL-CORE contixil 
interpretation of a 3 or 4 octet **address field" and a data link identification (DLCI) field. The minimum and default 
length of the address field is 2 octets and it may be extended to 3 or 4 octets to support a larger DLCI address range or to 
sv^^port the Optional DL-CORE control fimctions. The 3-octet or 4-ociet address field formats may be siqiporled at the 
user-netwoiic iixtej&ce or the network-network inter&oe based on bilateral agreement 

A.3.3 Address field variables 

A.3.3.1 Address JUld extension bit (EA) 

The definition and use of the £A bit is discussed in § 3.3.1. 

A.3.3.2 Command/response bit C/R 

The C/R bit is not used by the DL-CQRB protocol The coding is ^plication specific. The C/K bit is conveyed 
transparently by the DL-CORE protocol between DIX^OKE services users. 

A.3.3 .3 Forward explicit congestion notification (FECN) 

This bit may be set by a congested network to notify the user tiiat congestion avoidance procedures sbould tie 
initiated where applicable feat trafBc in the direction of the fr«me carrying the FECN indication. This bit is set to I to 
indicate to the leceivinB end-eystem tiiot the frames it reoeivas have encourUered congested resources. This bit may bt 
used by destination controlled transmitter rate adjustment 
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Default address 
fidd fom»t 
(2 Bytes) 



3 ocwtaddiess 
field fonnat 



4 octet addnaa 
field fonnat 



D/C 

DE 

EA 
* 

FECN 
BECN 
DLCI 



DLCI or DL-CORE oontrol iodicaior (see § A.3.3.7) 
Discard eligibility indicBtor (see § A.3.3.S) 
Address field extcnSJOll bit (see S A.3.3.1) 

Bit intended to support ft coramand/response indlcadon. The coding is application specific (sec § A.3.3.2) 
Forwani explicit congestion notification (see § A J. 3.3) 
Backward explicit congcsticm notification (sec § A.3.3.4) 
Data link connection identifier (sec § A.3.3.6) 



a 7 


6 


5 


4 


3 


2 


1 


Upper DLCI 


m 


EA 
0 


Lower DLCI 


FECN 


BECN 


DE 


EA 
t 






or 










6 7 


6 


5 


4 


3 


2 


1 


Upper DLCI 


* 


EA 
0 


DLQ 


FECN 


BECK 


DE 


EA 

0 


Lower DLCI or 
DL-CORE control 


D/C 


EA 
I 






or 










8 7 


6 


5 


4 


3 


2 


1 


Upper DLCI 


« 


EA 
0 


DLCI 


FECN 


BECN 


DE 


EA 
0 


DLa 


EA 
0 


Lower DLCK or 
DL-CORE control 


D/C 


EA 
I 



FIGURE A-2/Q.922 
Address field formats 
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While aettiQg tbia bit by the network or user is optional» ao network shall ever dear (set to 0) this bit. 
Networks that do not provide FECN shall pass this bit unchanged An example of the use of this bit is contained is 
Appendix I. 

A.3.3,4 Backward eJiplicitcOftgesHon notification (BECN) 

This bit may be set by a congested network to notify the user that congestion avoidance procedures should ba 
initiated, where applicable for tia£Eic in the opposite direction of the frame carrying the BECN indicator. This bit is to 
1 to indicate to the receiving end-system that the frames it transmits may encounter congested resources. This bit may be 
used by sovjrce controlled traitsniitter rate adjustment 

While setting this bit by the network or user is optional, no network shall ever clear (set to 0) this bit 
Networks that do not provide BECN shall pass this bit unchanged. An example of the use of this bit is contained in 
Appendix I. 

A.3.3.5 Discafd eligibility indicator (DE) 

This bit| if used* is set to 1 to indicate a request that a frame should be discarded in preference to other frames 
in a congestion situation. Settit;^ of this bit by the network or user is optional No network shall ever clear (set to 0) this 
bit Networks that do not provide DB shall pass this bit unchanged. Netwoiks are not constrained to discard only frames 
with DE =s 1 in the presence of congestion. 

A.3.3.6 Data link connection identifier (DLCJf) 

The DLd has a default length of 10 bits. The extension bit may be used to optionally increase the length to 16, 
17 or 23 bits, as shown in Figujre A-2/Q.922. The ranges for the DLCI values are shown in Table 1/Q.922. As discussed 
m § 3 the D/C indication may affect the length of the DLCI. 

A.3.3.7 DLd/DL-CORE control indicator (D/C) 

The definition and use of D/C are discussed in § 3.3.7. 



A.4 Placement of the DZ^ORE protocol in the ISDN protocol architecture 

This section describes die placement of the DL-CORE protocol in the context of a layered ardutecture. The 
concepts of the OSI reference model (see Recommendation X.200 [12]), the OSI sendee conventions (see 
Recommendation X.210 [13]), and the ISDN protocol reference model (see Recommendation L320 [14]) are used. The 
defmidon of layer to layer communication and a general introduction to the frmctional model is given in § 4. For this 
annex, a representative model is presented also for the sublayer communication with the DL-CORB Sublayer, 

The Fig;ures A-3/Q.922 and A-4/Q.922 depict the model which represents primitive interactions with messages 
for the support of the core service accorcUng to Reconmiandation 1^3 [1]. 

The U-pIane layer 2 is subdivided into: 

a) a DL-CONTROL Sublayer; and 

b) a DI^CORE Sublayer. 

The DL-CORE Sublayer provides core services to the user, a DL-CONTROL Sublayer, at the DL-CORE- 

SAP. 

The model shown in the frguxes covers both frame relaying and frame switchmg. In die case of frame lelayin^, 
tiie DL^ONTROL Sublayer endties at the network side are not present. 

The signal flows ai« based upon those shown in Figures 3/Q.922 through 6/Q.922. Figure A-3/Q.922 depicts 
frie signal flows at the calling access and called access inter&ces. Figure A-4A}.922 depicts the sigtial flows at the 
lelaasing access and released access inter&ces. 
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Table A-VQ.922 illustrates the primitives defined fbr che core aspects of LAPP. 




TABLE A-1/Q.922 
Frlcnldve types 





Type 


Parametflr 


Message unit 
contenta 


Generic name 


Ro- 

quBSt 


Indi- 
cation 


Response 


Confirmation 


Priority 
indicator 


Message 
unit 


Layer 3 — Layer2 managozneat 




M2N-ASSIGN 


X 










X 


Dl^CEI, DLCI 
















(Note 1) 


M2N'REMOVE 


X 










X 


DLCI 


DL-Core user — DL-Core 






DL-CORE-DATA 


X 


X 








X 


See § A.4.2.2 


DL-CONTRQL — Layer 2 inanasement 












MDL-ASSIGN 


X 










X 


DL-CEI 


MDL-REMOVE 


X 










X 


DL^ORE CEI 


DL-Core — Layer 2 managemeEit 




MC-ASSIGN 


X 


X 








X 


DLCI» 

DL-CORE CEI 


MC-REMOVE 


X 










X 


DLCI 


Layer 2 — Layer 1 




PH^DATA 


X 


X 






X 

(Note 2) 


X 


Data link layer 
pecr-to-peer message 



Note I — Optional parameterB; if missing, default values art used or pfoeedttres of Appendix HI are used. 

Note 2 — A priority indicator for layer 1 is not present in Recommendation X.21 1 [9] and Is used only for the basic rate interface 
D-cbanneL RmnBrnendation X.21 1 [9] does not consider priority as a layer 1 quaiiiy of service parameter. 



A.4. 1 Support by the underlying physical layer service 

The physical layer service is defined in the OSI physical layer service definition (see Reconmien- 
dation X.211 [9]). Only duplex (two-way simultaneous), point-to-point synchronous transmission is used. The optional 
PH-<]onnection activation and deactivation services of the physical layer are not presently used to support the DL-CORE 
protocol. 

A.4.2 DI^CORE service 

Recommendation L233 [1] provide a layer service desci^tion for the DL-CORE Sublayer. The DL-CORE 
protocol 1^ used to provide and supped this layer aervice, 

A.4J2.1 Primitives 

The DL-CORE DATA primitives are described in Annex B of Recommendation 1233 [1]. 
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A-4.2.2 Parameters 




The parameters associated with the DL-CORE DATA primitives are defined in Annex C of Recomaiendation 
1.233 [1]. The mapping of these ccm services paianneteis to DL-CORE-PDU fields is as follows: 



Core service parametBr 
(dflfiiied in ReoomineDdatifm 1.233 [1]) 


DL-CORE DATA 
primidve 


DL-CORE-PDU 
field 




Request 


Indiration 




DL-OORE user data 


X 


X 


Information ftetd 


Discard eligibility 


X 




Discard eligibility 


CongeatiDii enoountered backward 




X 


BECN 


Congefidon encoumer^d fbtwaid 




X 


FECN 


DL-CORB service user proueol 
control bifonnatlon 


X 


X 


C/Rbit 



A.4.2J Procedures 

A>l.2.3.1 Primitives/Frame relay fiwne mappings 

When a DL-CORE entity receives a DL-CORE DATA request from the DL-CORE service user, it sends a 
fianse relay fiame to Its peer. 

When a DL-CORE entity receives a valid frame relay frame, It signals a DL-CORE DATA indication to Khe 

DL-CORE service user. 

A.4.2.3.2 Parameters/fields makings 

Hie parameters to the DL-CORE DATA request and IX-CORE DATA hidication pritcdtives aie directly 
mapped to the fields of the frame reUy fifame as sho^ in § A.4.2.2. 

A.4.3 Layer management 

Table A-1/Q.922 shows the primitives exchanged between the DLCORE Sublayer management entity and the 
DL-CORE Sublayer entity. 

A.4.3.1 Primtives 

A.4.3.K1 MC-ASSIGN request 

The MC-ASSIGN request primitive is used by the layer management entity to: 

- signal to the DL-CORE Sublayer entity that a DLCORE Cottneetion has been establishedp 

- convey the DLCI agreed to be used between DL-CORE entides in support of that Core-connection, 

- convey die associated DL-CORE Connection Endposnt Identifier to be used uniquety idraiity die 
DL-CORE Connection and 

- convey the Connecdon Endpoint Identifier used to support the DL-CORE Connection. 
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A.43.1^ MaREMOVB tvquest / 

The MC-REMOVE request primitive is used by the layer management entity to signal to the DL-COR£ 
Sublayer entity that a DLCI has been released. 

A.4.3.1.3 M2N-ASSrGN 

The M2N-ASSIGN primitives are defined in § 4.1.1.10. 
A.4.3.1.4 M2N'EEM0VE 

The M2N-REM0VE primitives are defined in § 4.hl.U. 
A.4.3.1.5 MDL-ASSIGN request 

The MDI^ASSIGN request establishes a mapping in the DL-CONTROL Sublayer entity between the 
DL-COR£ CEI and the DL-Cm. 

A.4.3.L6 MDL'HEMOVE request 

The MDL^REMOVE request primitive is used by the layer 2 management entity to remove a mapping beCvmn 
a DL-CEI and a DL-CORE CEI. 

A.4.3.2 Parameters 

A.4.3^.I DLCI value 

The DLCI value parameter conveys the DLCI agreed to be used between DL-CORE Entities in si^ipon of a 
DL-CORE Connection. Its syntax and usage by the protocol ere defined in § 3.6. 

A,4.3 .2.2 DL-CORE Connection Endpoint Identifier 

The DL-CORE CEI uniquely identifies a DL-CORE Connection. It is defined in Recommendadon 1.233 [1]. 
A.4.3,2.3 DL'Cormectioft Endpoint Identifier 

The DL-CEI uniquely identifies a DL-Connection. 
A-4.3.2.4 Physical Connection Endpoint Identifier 

The physical Connection Endpoint Identifier uniquely identifies a physical Connection to be used in support of 
a DL-OORE Connection. 

A.4^.3 Procedures 

For pemianent ^^mc relay bearer connections, information related to the opemtion of the DL-CORE protocol 
in support of DL-CORE Coimections is oKiintained by DL-CORE Sublayer management. Far demand fi^me relay bearer 
connecdons, the layer 3 establishes and releases DL-CORE Connections on behalf of the DL-CORE Sublayer. 
Therefore, information related to the operation of the DL^ORE protocol is maintained by coordination of layer 3 
management ml DL-CORE Sublayer management through the operadon of the local systems environment. 
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A.4.33. 1 DL'CORE connection estabiishment 




When it is necessary to notify the DL-COB£ Sublayer entity (either because of establishment of a demand 
fiwfne relay cal]> becaiise of notification of re-establishment of a pennanent fi^me relay bearer connection or because of 
system inidalization) that a DL-CORE ConiMction is to be established, the DL-CORE Layer management entity signals 
an MC-ASSIGN request primitive to the DL-CORE Sublayer entity. In addition, the Layer 2 miuiagement entity initiates 
an MDL-ASSIGN request to the DL-CONTROL Sublayer entity. 

The DL-CORE Sublayer entity establishes the necessary mappings between the supporting physical 
Connection, the DL-CORE CEI and the DLCL In addition* if it has not already done so, it begins to transmit flags on the 
I^iysical Connection. 

The DL-CONTROL Sublayer entity establishes the necesaaiy mappings betwaan the DL^I^ORE GET and the 

DL-CEI. 



A.4J.3.2 DL-CORE eomection release 



"When it is necessary to tJiotily the DL-CORE Subl^er entity (dthw because of release of a demand frame 
relay call or because of notification of failure of a pemianenc frame relay bearer connection) that a DL-CORE 
Connection is to be released the DL-CORE Layer management entity signals an MC-REMOVE request primitive to the 
DL-CORE Sublayer entity* and an MDL-REMOVB request to the DL-CONTROL Sublayer entity. 



The DLOORE Sublayer entity removes any mappings between the sc^porth^ physical Connecdon, the 
DL-CORE CEI and the DLCL 



The DL^ONTROL Sublayer entity removes any mapping between the DL^ORE CEI and the DL-CEL 



A.S List of system parameters 

The system parameters bsted below are associated with each individual firame relaying connecdoxL 



A.5. 1 Maximum number of octets in ofxime relaying information field (N203) 

The detault for the maximum number of octets in a frame relaying information field is 262 octets (i.e. N201 
2). The minimum frame relaying information field size is one octet. The default maximum size was chosen for 
coxD^tible operation with LAPD on the D-channel, which has a 2 octet control field and a 260 octet maximum 
information flel± All other maximum values are negotiated (e.g. using Q.933 procedures) between users and networks 
and between networks. The support by networks of a negotiated maxiTniim value of at least 1600 octets is strongly 
recommended for applications such as LAN interconnection to minimize the need for segmentation and reassembly by 
the user equipment 



A.6 Congestion control procechjres 

Congestioa in the user plane occurs when traffic arriving at a resource exceeds the network*s capacity. It can 
also occur for other reasons (e.g. equipment &i]ure). Network congestion affects die throughput rate* delay arid frame 
loss cxpedcxaed by the end user. 

End users should reduce, their offered load in the fkcc of network congestion. Reduction of offered load by an 
end user may well result in an increase in the effective throughput available to the end user during congestion. 
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CongestioQ control may be achieved by: 
]) congesdon avoidance zncchanisma, and/or 
li) congestion recovery mechanisms. 

Congestion avoidance (see Note) mechanisms, as discussed in §§ A.6.2 and are used at the onset oi 
congesdon to miniizuze its negative effect oxi the network and the user. 

JVote- Congestion avoidance, as defined in Recommendtion L370 [10], is intended to minimize degradation fa 
the quality of service. The specification of the degtee of degrsdatioo k beyond the scope of this Recommendation. 

Congestion recovery meduuusms, as defined in § A.6.U are used to prevent network collapse in tihe face oi 
severe congestion. 



Congestion avoidance and congestion recovery are effective and complementary fonns of congestion control 
in firame relBying networks. 

A.6.1 Implicit congestion detection 

For implicit congestion detection schema, the frame relaying network does not send an indication to the user. 
Implicit congestion schemes involve certain events available in the layer 2 elements of procedures to detect the frame 
loss (e.g. receipt of a REJECT fiame, timer recovery, etc.). 

The intent of this scheme is to reduce Ihe offered load to the network by the end user. Use of such reduction by 
users is optional An example otoDs approach is discussed in § LI. 

A.6.2 EjspUcit nQtification 

Explicit notification is a procedure used for congestion avoidance. Explicit notification is a part of die data 
transfer phase protocol. Users should react to explicit congestion notification (l.e, the reaction is a highly desirable 
option). Users that are not able to act on explicit congestion notification shall have the capability to receive and ignore 
eT^licit notification generated by fht network. 

Reaction by the end user to the receipt of explicit congestion notification is rate based. 

A.6.2. 1 Explicit congestion sisals 

Explicit congestion signals are sent in both forward (towards frame destination) and backwaixi (cowards frame 
source) directions. Forward explicit congestion notification is provided by using the FBCN bit in the address field. 
Backward explicit congestion notification is provided by one of two methods. When timely reverse traffic is available, 
the BECN bit in an appropriate address field may be used, Otherwise, a single cot)SOlidated link layer managenwnt 
message may be generated by the network (see § A.7). The ConaoKdated link layer management (CLLM) message 
tmvels on the U-plane pl^ical path, me generation and transport of CLLM by the network is optional. 

All networks must transport the FBCN and BECN bits without resetting. 

A.6.22 Rate reduction strategy 

The specific rate reduction strategy to be used by end users is not identified. An Qxanq)le is discussed in § 1.2. 



A.7 Consolidated link layer monagement (CLU^ message 

The consolidated link layer management message is based on ISO 8885 [15] definition of ti» use of XID 
frames for the transport of functional information. The gomation and transport of tise CLLM are optionaL 
Figuras A-5/Q.^ and A-€/Q.922 iUustrate che format of tins frame. Each parameter Is described using tiie seqi^nce 
t>pe - length ^ vahie. The following subsections describe the functional fields for die consolidated link layer 
management message. All fields are binary encoded unless otiierwise specified 
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Ocut 


Bits 


Field naoiie 




8765432) 




1 


1 1 1 I 1 OR 0 


Address octet 1 (R indicates '^response**) 


2 


11110001 




3 


I 0 1 0 1 1 1 1 




4 


1 000001 0 


Format idontifiaT ^ll^O'i 


5 


0000 1 1 1 i 


OrouD identififlT =15 rPrivBtB mmnfltefs nenAttAtlofil 


$ 




GmuB lenffth oAMt 1 


7 




Gtouii lenoch ngfat 3 


8 


00000000 
vvvvvvvw 


raniiuBwr iwanm icr ™ v ^irareiniKeT act iBBnuiicBuun^ 


0 


00 000 100 




10 


01 1 0 1 00 1 


PftfflHWtei* valuH M 10S Efidfffl "Tl 
rMaimwr vmub m\u \it\mi cuueii 


1 1 

1 1 


00 1 1000 1 






00 1 10010 


irliraiTIOIOr yBIwC ' JU ^l/W GOUCu 


13 


0 0 I 10 0 10 




14 


000000 1 0 

VVVVWV « w 


PfirAmctcr idiwtificf * 2 ^c^ra idl 


IS 


00000 001 


Pamneter length ■ 1 


16 




^HllBA VIlll1# 


17 


00000 oil 

VVVVVWl 1 


PftramPtlMP vn In a ■ ^ tT\T f^l irfMttjfiii>r^ 
Jroi B&uouir VlUiiP " J IQGunTlCl^ 


1 o 




r luiicxjCfcor iDngui 


19 




l^JLAn/l VCIIII9 vvI^C^ 1 






li/LArfi vaiuo uuim a 


ii 
ff 




ft 


2n+17 




DLCI value octet (n-di DLCI) 


2n + 18 




DLCI volaB octet (n-th DLCt) 


2n+I9 




PCS octet 1 


2d + 20 




PCS octet 2 



FrCURBA-5/Q.922 

Consolldatea lioU layer numaeeinent messafe <B* or H-channd) 
lulng 2 octet address field 
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Octet 

1 
2 
3 
4 
5 



2d +19 
2n + 20 



Bits 

87654321 



] 1 1 1 lORO 

mini] 

10101111 
10000010 
00001 I 1 1 

// 



Fieldname 



Address octet 1 (SAPI = 62) (R indicates ''response") 
Address octet 2 (TEI - a?) 
XID conml field 
Format identifier (] 30) 

Group idem. » 15 (Private parameters tiegotiaiion) 

Octet 6 to 2n -f 1 8 as for B- or H-chantiels in Figure A-S/Q.922 

// 

FCS octet 1 
FCS octet 2 



FIGURE A-6/Q.922 

Consolidated link layer manQgement message (D-ehannel) 
using 2 octet address Add 



A.7.1 Address octets 

The default address size of two octets is used in the foliowlng specificatjon. 
Note - The use of GLLM for 3 or4 octet address fields is for fbrther study. 

Octets 1 and 2 represent the address field for a de&ult two octet address. The first octet includes the 6 bit 
yxppet DLCt subfield. The second octet inohMles the 4 bit lower DLCI subfield. 

The CLLM message is sent in an XID-response frame. Except when delivered on a D-channcl, it is sent in the 
management DLCI as shown in Figure A-5/Q.922. The congestion indication bits and me discard eligibility indicator are 
not used m this case and should be set to "0*\ When delivered on the D-channeL it is sent using a two octet address field 
with bits 8 to 4 of the first address field octet and bits 8 to 2 of the second address field octet set to and bit 3 of the 
first octet set to *'0" as shown in Figure A-6/Q.922. The congestion indication bits and the discard eligibility indicator do 
not exist in this case. 

Note -The use of the CLLM for semi-pennanenl finan^ relay connections using D^hannel access requires 
further study. 

Octets ] and 2 of the XID frame represent the address field and bit 2 of octet 2 is the command/response bit 
(C/R). In a congestion control application, the receipt of a congestion message should not result in transmission of a 
subsequent &ame^ which would add to the traffic oongesdoo. Therefore, the CXXM shall be sent in an XID response 
frame, Le. the C/R bit shall be set to T*. 

AJ2 Contro! field 

Octet 3 contains ib& control field code point for this type of me^ge. This represents the control field for XID. 
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A.7.3 XID iitformation field 
A.7.3.1 Fomutt identifier field 



Octet 4 CQQtauts the fonnat identifier field. ISO defines fbs format identifier field to have a lengOi of one octet 
ISO 8885 [15] assigns the value of 130 decimal as a general purpose format identifier, end it is used by layer 
man a ge m en t for paiameter negotiation as discussed in Appendix m. 

A.7.32 Group fieid 

A.7^.2.1 Oroi^ identifier fieid 

Octet 5 contains the group idaitifier field. The group identifier field is "15** decimal, wliich is assigned by ISO 
8885 [IS] to iiuficote private parameters. 

Note In the context of ISO 8885 [15]-Addendum 3, "private'* is taken to mean a parameter b^ond the scope 
of the HDLC specific paraneteis defined in ISO 8885 [15]. 

A.7.3.2^ Group length field 

Octets 6 and 7 contain the group length field This 16-b2t field describes the "length" of the octets in the 
remainder of the group field. The maximum value of the group length field is 256 for compatibility with the D-channeJ 
applications where the information field is a maximum of 260 octets. 

A.7.3.2.3 Group value field 

The group value field consists of two or more parameter fields. The pai^eter Set identification^ parameter 0, 
idendfies the set if private parameters within Che group value field per ISO 8885 [15]/DAX> 3. The other parameters shall 
appear in die following order: cause identifier and then DLCI identifier. 

A.7,3 .3 Parameter fifr parameter Set identification 

The parameter Set identification parameter shall always be present; otherwise* the fiame shall be rejected. 

A.7 J.3. 1 Parameter Set identification field 

Octet 8 contains the parameter identifier field for the first parameter and is set to '^O"" per ISO 8885 [15]/DAD 
3. Parameter 0 identifies the set of private parameters widiin this group. 

A.7.3 J.2 Parameter Set identification length field 

Octet 9 contains the length of parameter 0 and is set to binary ^^4''. 

A.7.3 J.3 Parameter value field 

Octets ID to 13 identify that this usage of the XID frame private parameter group is for 1.122 [1 1] private 
parameters. Octet 10 contains the IA5 value of *T' (binary 105). Octet 11 contains the IA5 value of (biaSiiy 49). 
Octets 12 and 13 each contain the IA5 value of "2" (binary 50). 

A.7.3.4 Parameter field fi>r cause identifier 

The cause identifier shall always be present; otiuerwise, the fi^me shall be ignored. 

A.7.3.4. 1 Parameter identifier field 

Octet 14 contains the cause identifier field. When the parameter identifier field is set to **2'*» then the following 
octets of Oils parameter contain a loigdi parameter set to " 1** and a cause value. 
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A.7.3-4.2 Parameter length field 

Octet IS contains the length of the cause identifier. This shall be set to bioaiy "'V\ 

A.7 Cause value 

Octet 16 contains the cause v^ue. This octet Identifies the cause of this message as detennined by the 
congested netwoik node whose layer management module originated the message. 



la 054/060 



Bits 


Cause 


S765432 1 




OOOQOOlO 


Network congestion due to excessive trajfie 


0000001 1 


Network congdstion due to excessive trafVle 


00000] 10 


Facilicy or equipment fiiilure — short tarm 


000001 1 1 


Facility or equipment failure — lone term 


00001010 


Mainteimnco action — short temi 


0000101 1 


Maintenance action — long tcm 


00010000 


Unknown — short terrn 


00010001 


Unknown ^ long temi 


All other vaiuGs are 
reserved 





The CLLM message shall not be ignored solely because of an unknown cause value. 

Noi^ - Cause values shall be coded as "shon term** if die CLLM is sent due to a transient condition (e.g. one 
anticipated to have a duration on the order of seconds or minutes); otherwise, they shall be coded as "long term**. Usage 
shall be network specific. 



A.7.3,5 Parameterfieldfor DLCI identifier 

If the DLCI identifier is missings then the frame shall be ignored. 



A.7.3.S. 1 Parameter identifier field 

When the parameter identifier field is set to '"3'', then the following octets of this parameter contain the 
DLCl(s) of the frame relay bearer connection's) that are congested. 

A-7.3.5.2 Parameter length field 

Octet 18 contains the length of the DLCI(8} being r^orted, in octets. For exaniple, If (n) DLCIs are being 
rqx3rted and they are of lei^gdi two octets each, this will be 2 times (n) in octet size. 
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A.7,3.5,3 Parameter value field 

Octets 19 through to the FCS octets contain the DLQ vahie(s) which identify logical liakCs) thai havp 
encountered a congested state. The DLCI field is 10 bits long and contained in bits 8 to 3 of the first octet pair and bits 8 
to 5 of the next octet of the pair. Tlie bit 8 of tfie jSrat octet is 4e roost significant bit and bit 5 of the second octet is th? 
least significant. The bits 2 to 1 hi the first octet and bits 4 to 2 m the second octet are reserved. 



A.7.4 FCSfield 



The last two octets of the frame contain the frame check sequence field. 

A.7.5 ActiQn of the congested node 

When a node becomes congested, it may send notification of the congested state by setting forward and 
backward congestion bits to "1" in the address field and/or using a consolidated link layer management message on tiie 
management data link. The purposes of the explicit congestion noti&atian are: 

1) to infonn the edge node at the network ingjrcss of the congestion so that the edge node can take 
appropriate action to reduce network congestion; and/or 

2) to notify the source that negotiated throughput has been exceeded. 

The consolidated link layer management message contains a list of DLCIs that correspond to the congested 
frame relay bearer connections, These DLCIs will correspond both to sources that are cutrently active and those that are 
, not The puipose of the latter action is to prevent those sources from becoming active and hence inci«asmg congestion. It 
rnqr be necessary to send more than one consolidated link layer management noessage, if all DLCIs cannot fit within a 
single frame. 



ANNBX B 
(CO Recommfittdation Q.922} 

SDL for point-to-point procedures 



B.l General 



The puipose of this annex is to provide one example of an SDL representation of the point-co-point procedures 
of the data link la3rer, to assist in the undei^taoding of this Recommendation. This representation does not descrit>e all of 
the possible actions of the data Imk layer entity^ as a non-partidoned repres^tation was selected in order to minimize its 
complexity. The SDL representation, therefore, does not constrain inq>lementations from exploiting ftdl 8C(^ of the 
procedures as presented within the text of this Recommendation. The text descripdon of the procedures is definitive. 

The representation is a peer-to-peer model of the point-to-point procedures of the data link layer is 
applicable to the data Jink layer entities at both the user and netwoik sides for all ranges of DLCIs. The model is the 
same as that used for Rec^unmendation Q.92] [2] and Figure B-1/Q.922 demonstrate a graphical representation of the 
ncKHlel. 
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8 7 6 S 4 3 2 I ' ' I 





Flag 






V 


t 1 1 1 1 

\ V \ \ \ 


1 A 


Octet 1 




High order octet of address fteld 


(Note) 


2 




I^ow Order octet of addtesB field 




3 








4 




Frame relay infonrution field 




N-3 








N-2 




Frame check sequence (FCS) 2nd octet 




N-1 




Flag 






0 


11111 


1 0 


N 



Nctm - The default address field length is 2 octets. It may be extended to eidier 
3 or 4 octets bilaterai agreement 

nOUKEA-l/Qra 
Fnme relay R^me format with two octet address 



K2A Control field 

A coatrol field, as seen by the DL-CORE Sublayer, does xiot exist in a frame relay frame structura, 

A.2.5 Frcane relcying information field 

The fiame relaying mformation field of a frame, when present, follows the address field (see § A.3.2) and 
precedes the frame check sequence field (see § A.2.7). The contents of the firame relaying infonnatioii field shall consist 
of an integral number of octets. 

The maximmtx number of octets in the frame relaying mformation field is defined in § A.5. 1. 

A.2,6 Thxnsparency 

A transmitting data link layer entity shall examine the fisme content between the opening and closing flag 
sequences, (address, infonnation and FCS fields) and shall insert a ""iT bit after all sequences of five contiguous "1" bits 
(inchiding the last five bits of the FCS) co ensure that a flag or an abort sequence is not simulated within the tone. A 
receiving data link layer entity shall examine the frame contents between die opening and closing flag sequences and 
^1 discard any "0** bit which directly follows five contiguous T bits. 

A^.7 Fram^ checking sequence (FCS) field 

The definition and use ofthe FCS 13 as described in §2.7. jy ^ I i 
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Doftiilt address 
field format 
(2 Bytes) 



Upper DLCI 


* 


EA 
0 


Lower DLCI 


FBCN 


BECN 


DE 


EA 
1 



or 



3o6tetftddi«fld 
field fbimfit 



Upper DLCI 


* 


EA 






0 


DLCT 


FECN 


BECN 


DE 


EA 










0 


Lower DLX:i or 


D/C 


EA 


DL-CORE control 




1 



or 



8 7 6 5 4 3 1 1 



4 octet address 
field fbnnat 


Upper DLCI 


* 


EA 
0 




DLCI 


FECN 


BBCN 


DE 


EA 
Q 




DLCI 


EA 
0 




Lower DLCI or 
DL-CORE control 


D/C 


EA 
1 



D/C 


DLCI or DL-CORE control mdicator (see § A.3.3.7) 


D£ 


Diseeid eligibilicy indicaxor (see § AJ.3.5) 


EA 


Address field extension bit (see § A.3.3.1) 


n 


Bit mtoided to support 9 command/response indication. The coding is application specific (see § A.3 J^) 


FECN 


Forward explicii congestion notifieatiOQ (sec § A.3 J.3) 


BECN 


Backward explicit congestion notification (sec § A.3.3.4) 


DLa 


Data link connection identifier (see § A3.3.6) 



FIGtmE A-2/Q.922 
Addreai field fonoats 
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d) contams a frame ch^k sequence error; 

e) contains a single octet address field; or 

f) contams a DLCI which is not supported by receiver. 

Invalid frames shall be discarded without notification to the sender. No action is taken as the result of invalid 

frames > 

2.10 Frame aborts 

The dfifinition of and the reaction to fanne aborts is as in Recommendntion Q,92 1 [2]. 

3 Elements or procedures and formats of fields Itar data Kink layer peer-to-pcer communlcatloii 

3.1 General 

The elements of procedures define the commands and responses that are used for peer-to-peer communication 
using the data link layer connections. 

Procedures are derived from these elements of procedures and are described in § 5. 

3 .2 Address field formal 

The address field format shown in Figure 1/Q.922 contains the address field extension bits, a 
command/response indication^ 3 bits reserved for forward and backward explicit congestion notification and discard 
eligibility (used with frame relaying services per Annex A), a data link connection ideniififir (DLCI) field and a bit to 
indicate whether the final octet of a 3 or 4 octet ^'address field" is lower DLCI or DL-CORE control (see § 3.3.7) 
information. The minimum and default length of the address field is 2 octets and it may be extended to 3 or 4 octets to 
support a larger DLCI address range or to support optional DL-CORE control functions. The 3-oct6t and 4^ctet address 
field formats m^ be supported at the user-network inter&ce or at the network-network interface based on negotiation or 
bilateral agreement. 

The support of address fields longer than cwo octets is an option chosen by bilateral agreement. This option 
includes distinctions for supporting the address field length varying on an bterface basis or on a per channel basis* 

3J Address field variables 

3.3. 1 Address field extension bit (EA) 

The address field range is extended by reserving ^e first transmitted bit of the address field octets to indicate 
the final octet of the address field. The presence* of a 0 in the first bit of an address field octet signals that another octet 
of the address field follows this one. The presence of a 1 in the first bit of an address field octet signals that it is the final 
octet of the address field. For example, the two octet address field has bit one of the first octet set to ^'0** and bit one of 
the secotkd octet set to 

3 .3.2 Command/response field bit (C/R) 

The C/R bit identifies a frame as either a command or a response. When the frame to be sent is a command 
fiame, the C/R bit shall be set to 0. When the fiame to be sent is a response &ame, die C/R bit shall be set to L 




3,3.3 Forward expUcH congestion notification bit (FECN) 

This bit is reserved for use with frame relaying service, as described in Annex A and Appendix I. 
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3 octBta addreas 
field ibnnat 



4 octets address 
field fbrmflt 



or 



De&uh address 
field fcmiat 


Upper DLa 


C/R 


EA 
0 


(2 octets) 


Lower DLCI 


FECN 
(Mote) 


BECN 
(Note) 


DB 
(Note) 


EA 
I 



EA Address field extension bit 

C/R Contonend response bit 

FECN FonvBjid eT^licit congestion notificatiott 

BBCN Backward expKcic congestion cotiflcatioa 

DLCI Data link connection identifier 

D£ Discard eligibility indicator 

D/C DLC! or DLrCORB control indicator 



Upper DLCI 


C/R 


EA 
0 


DLCI 


FECN 
(Note) 


BECN 
(Note) 


DB 
(Note) 


EA 
0 


Lower DLCI or 
DL-CORE Corttroi 


D/C 


EA 

1 


or 

6 7 6 5 4 3 2 1 


Upper DLCI 


C/R 


EA 
0 


DLCI 


FECN 
(Note) 


BECN 
(Note) 


DB 

(Note) 


EA 

0 


DLa 




EA 
0 


Lower DLCI or 
DL-COKE control 


D/C 


EA 
1 



UQt€, ~ See Annex A and Appendix I fs3x the use of these 3 bits whtche are reserved for congestion notification signallipg with frame 
relaying. 
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3.3.4 Boch^ford explioit congestion notification bit (BECN) 

This bit is reserved for use with frame relaying service, as described in Annex A and Appendix 
23*5 Discard eiigibility indicator (DE) 

This bit is reserved for use with frame relaying service, as described in Annex A and Appepndix I. 



3.3.6 Data link connection identifier (DLCI) 




The DLCI identifies 8 virtual connection on a bearer channel (i.e. D, B or H) at a user to network or network to 
network interjfoce. Consequenfly, a DLCI specifies a data link layer entity to/fiom which infbnnation is 
delivered/received and which is to be carried in frames by data link layer entities, The OLd field may be either 
unstructured or structured. In the former case, the least significant bit is determined as follows: 

Address field 0/C 0 D/C - 1 

size 

2 octets (Note) (Note) 

3 octets bit 3 of octet 3 bit 5 of octet 1 

4 octets bit 3 of octet 4 bit 2 of octet 3 

Note - Not applicable; least significant DLCI bit is bit 5 of octet 2. 

A structure to the DLCI field may be established by the network at the user to network interface or at a 
networic to network interface subject to negotiation or bilateral agreemeoL 

For notation purposes, the 6 most significant bits (bits 8 to 3) in the first octet of the address field (which 
corroE^ond to the SAPI field in Recommendation Q.92 1 [2]) axe refeired to as the upper DLCL 

Table 1/Q.922 shows the ranges of DLCI values vAnch apply for specific functions to ensure compatibility 
with operation on a D-K:hannel« which also may use the Q.921 [2] protocol A two octet address field fonnat for this 
Recommfindstion is assumed when used on a E^-channel. For further study is whether 3 or 4 octet address field fonnats 
may be tised on a D-channeL 

3.3.7 DLCJ/DL'CORE control indicator (O/Q 

The D/C indicates whether the remaining six usable bits of diat octet are to be interpreted as the lower DLCI 
bits or as DL-CORE control bits. The bit is set to 0 to indicate that the octet contains DLCI information. This bit i$ set to 
1 to indicate that the octet contains DL-CORE control information. This indicator is limited to use in the last octet of the 
three or four octet type "address field". The use of this indication for DL-CORE control is reserved as there have not 
been any additional control functions defined which need to be carried in the **address field"; this indicator has been 
added to provide for possible future expansion of the protocol. 

Note - The optional DL-CORE control flekl is pan of the address field and therefore must not be confused 
with the control field of an HDLC frame as defined in Figure 1/Q.921. 



3.4 Conirol field formats 

The control field identifies die type of frame, ^ch will be either a command or response. The control will 
contain sequence numbers where applicable. 

Three types of control field fonnats are specified: numbered information transfer (I fbimat)« sitpervisoiy 
fiacfions (S fbrmat), and unnumbered information transfeis and control fimctions (U fbrmat). Tht control field formats 
are shown in Table 2/Q.922. 
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